71 - Payment Protocol MIME types
BIP: 71 source Layer: Applications Title: Payment Protocol MIME types Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0071 Status: Final Type: Standards Track Created: 2013-07-29 Table of ContentsAbstractMotivationSpecificationExample Abstract This BIP defines a MIME (RFC 2046) Media Type for Bitcoin payment request messages. Motivation Wallet or server software that sends payment protocol messages over email or http should follow Internet standards for properly encapsulating the messages. Specification The Media Type (Content-Type in HTML/email headers) for bitcoin protocol messages shall be: Message Type/Subtype PaymentRequest application/bitcoin-paymentrequest Payment application/bitcoin-payment PaymentACK application/bitcoin-paymentack Payment protocol messages are encoded in binary. Example A web server generating a PaymentRequest message to initiate the payment protocol would precede the binar...
72 - bitcoin
BIP: 72 source Layer: Applications Title: bitcoin: uri extensions for Payment Protocol Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0072 Status: Final Type: Standards Track Created: 2013-07-29 Table of ContentsAbstractMotivationSpecificationCompatibilityExamplesReferences Abstract This BIP describes an extension to the bitcoin: URI scheme (BIP 21) to support the payment protocol (BIP 70). Motivation Allow users to click on a link in a web page or email to initiate the payment protocol, while being backwards-compatible with existing bitcoin wallets. Specification The bitcoin: URI scheme is extended with an additional, optional "r" parameter, whose value is a URL from which a PaymentRequest message should be fetched (characters not allowed within the scope of a query parameter must be percent-encoded as described in RFC 3986 and bip-0021). If the "r" parameter is provided and backwards compati...
34 - Block v2, Height in Coinbase
BIP: 34 source Layer: Consensus (soft fork) Title: Block v2, Height in Coinbase Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0034 Status: Final Type: Standards Track Created: 2012-07-06 Table of ContentsAbstractMotivationSpecificationBackward compatibilityImplementationResult Abstract Bitcoin blocks and transactions are versioned binary structures. Both currently use version 1. This BIP introduces an upgrade path for versioned transactions and blocks. A unique value is added to newly produced coinbase transactions, and blocks are updated to version 2. Motivation Clarify and exercise the mechanism whereby the bitcoin network collectively consents to upgrade transaction or block binary structures, rules and behaviors.Enforce block and transaction uniqueness, and assist unconnected block validation. Specification Treat transactions with a version greater than 1 as non-standard (offic...
61 - Reject P2P message
BIP: 61 source Layer: Peer Services Title: Reject P2P message Author: Gavin Andresen Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0061 Status: Final Type: Standards Track Created: 2014-06-18 Table of ContentsAbstractMotivationSpecificationrejectcommon payloadrejection codes common to all message typesreject version codesreject tx payload, codespayload, reject blockCompatibilityImplementation notes Abstract This BIP describes a new message type for the Bitcoin peer-to-peer network. Motivation Giving peers feedback about why their blocks or transactions are rejected, or why they are being banned for not following the protocol helps interoperability between different implementations. It also gives SPV (simplified payment verification) clients a hint that something may be wrong when their transactions are rejected due to insufficient priority or fees. Specification Data types...
13 - Address Format for pay-to-script-hash
BIP: 13 source Layer: Applications Title: Address Format for pay-to-script-hash Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0013 Status: Final Type: Standards Track Created: 2011-10-18 Table of ContentsAbstractMotivationSpecificationRationaleBackwards CompatibilityReference ImplementationSee Also Abstract This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin. In essence, an address encoded under this proposal represents the encoded hash of a script, rather than the encoded hash of an ECDSA public key. Motivation Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions. Enable third-party wallet secu...
11 - M-of-N Standard Transactions
BIP: 11 source Layer: Applications Title: M-of-N Standard Transactions Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0011 Status: Final Type: Standards Track Created: 2011-10-18 Post-History: 2011-10-02 Table of ContentsAbstractMotivationSpecificationRationaleImplementationPost History Abstract This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type. Motivation Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. A couple of motivating use cases: A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the propose...
109 - Two million byte size limit with sigop and sighash limits
BIP: 109 source Layer: Consensus (hard fork) Title: Two million byte size limit with sigop and sighash limits Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0109 Status: Rejected Type: Standards Track Created: 2016-01-28 License: PD Table of ContentsAbstractMotivationSpecificationMAX_BLOCK_SIZE increased to 2,000,000 bytesSwitch to accurately-counted sigop limit of 20,000 per blockAdd a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per blockActivation: 75% hashpower support trigger, followed by 28-day 'grace period'Expiration: 1-Jan-2018Backward compatibilityRationaleImplementationCopyright Abstract One-time increase in total amount of transaction data permitted in a block from 1MB to 2MB, with limits on signature operations and hashing. Motivation Continue current economic policy.Exercise hard fork network upgrade.Mitigate potential CPU exhaustion attacks Sp...
12 - OP_EVAL
BIP: 12 source Layer: Consensus (soft fork) Title: OP_EVAL Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0012 Status: Withdrawn Type: Standards Track Created: 2011-10-18 Table of ContentsAbstractMotivationSpecificationRationaleBackwards CompatibilityReference ImplementationSee Also Abstract This BIP describes a new opcode (OP_EVAL) for the Bitcoin scripting system, and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them. Motivation Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions in a way that is backwards-compatible for old clients and miners. Specification OP_EVAL will re-define the existing OP_NOP1 opcode, and will function as follows: When executed during transaction verification, pops the item from the top of the stack, deserializes it, and...
50 - March 2013 Chain Fork Post-Mortem
BIP: 50 source Title: March 2013 Chain Fork Post-Mortem Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0050 Status: Final Type: Informational Created: 2013-03-20 License: PD Table of ContentsWhat went wrongWhat went rightRoot causeAction itemsImmediatelyAlert systemSafe modeTestingDouble spendingResolutionCopyright What went wrong A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected fork of the blockchain. The pre-0.8-incompatible chain (from here on, the 0.8 chain) at that point had around 60% of the mining hash power ensuring the split did not automatically resolve (as would have occurred if the pre-0.8 chain outpaced the 0.8 chain in total work, forcing 0.8 nodes to reorganise to the pre-0.8 chain). In order to restore a canonical...
16 - Pay to Script Hash
BIP: 16 source Layer: Consensus (soft fork) Title: Pay to Script Hash Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0016 Status: Final Type: Standards Track Created: 2012-01-03 Table of ContentsAbstractMotivationSpecificationRationaleBackwards Compatibility520-byte limitation on serialized script sizeReference ImplementationSee AlsoReferences Abstract This BIP describes a new "standard" transaction type for the Bitcoin scripting system, and defines additional validation rules that apply only to the new transactions. Motivation The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted. Specific...
101 - Increase maximum block size
BIP: 101 source Layer: Consensus (hard fork) Title: Increase maximum block size Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0101 Status: Withdrawn Type: Standards Track Created: 2015-06-22 Table of ContentsAbstractMotivationSpecificationDeploymentTest networkRationaleObjections to this proposalCentralization of full nodesCentralization of mining: costsCentralization of mining: big-block attacksUnspent Transaction Output GrowthLong-term fee incentivesOther solutions consideredOne-time increaseDynamic limit proposalsCompatibilityImplementation Abstract This BIP proposes replacing the fixed one megabyte maximum block size with a maximum size that grows over time at a predictable rate. Motivation Transaction volume on the Bitcoin network has been growing, and will soon reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte maximum block size. Increasing the maximum size redu...
70 - Payment Protocol
BIP: 70 source Layer: Applications Title: Payment Protocol Author: Gavin Andresen Mike Hearn Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0070 Status: Final Type: Standards Track Created: 2013-07-29 Table of ContentsAbstractMotivationProtocolMessagesOutputPaymentDetails/PaymentRequestPaymentPaymentACKLocalizationCertificatesExtensibilityReferencesReference implementationSee Also Abstract This BIP describes a protocol for communication between a merchant and their customer, enabling both a better customer experience and better security against man-in-the-middle attacks on the payment process. Motivation The current, minimal Bitcoin payment protocol operates as follows: Customer adds items to an online shopping basket, and decides to pay using Bitcoin.Merchant generates a unique payment address, associates it with the customer's order, and asks the customer to pay.Customer copies the Bitcoin address ...
106 - Dynamically Controlled Bitcoin Block Size Max Cap
BIP: 106 source Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap Author: Upal Chakraborty Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0106 Status: Rejected Type: Standards Track Created: 2015-08-24 Table of ContentsAbstractMotivationSpecificationProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersRationaleProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersCompatibilityOther solutions consideredDeployment Abstract This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... i. Dependi...
123 - BIP Classification
BIP: 123 source Title: BIP Classification Author: Eric Lombrozo Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0123 Status: Active Type: Process Created: 2015-08-26 License: CC0-1.0 GNU-All-Permissive Table of ContentsAbstractCopyrightMotivationSpecification1. Consensus LayerSoft ForksHard Forks2. Peer Services Layer3. API/RPC Layer4. Applications LayerClassification of existing BIPs Abstract This document describes a classification scheme for BIPs. BIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs. Copyright This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses. Motivation Bitcoin is a system involving a number of different standards. Some standards are abso...